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Using a real-life evolution taken from the Graphical Modeling Framework, we invite submissions to 
explore ways in which model transformation and migration tools can be used to migrate models in 
response to metamodel adaptation. 



1 Model Migration 

Modeling languages and thus their metamodels are subject to evolution [2]. When a metamodel is 
adapted, existing models may no longer conform to the adapted metamodel and thus need to be migrated. 
Model migration is a special case of exogenous model transformation [7], since original and adapted 
metamodel are usually different from each other. However, the metamodel versions also share some sim- 
ilarity, as the metamodel is usually not completely changed during metamodel adaptation JT41 . Conse- 
quently, migrating transformation definitions usually contain identity rules for the unchanged metamodel 
parts. To remove this boilerplate code, different approaches have been proposed [13]. 

Manual specification approaches — like Sprinkle's language [14], MCL O and Epsilon Flock ifTTIl — 
extend transformation languages so that they automatically copy model elements that are unaffected by 
metamodel adaptations. Operator-based approaches — like Ecoral IPT51 and COPE fl4j — provide reusable 
operators that encapsulate recurring metamodel adaptations and model migrations. Metamodel matching 
approaches — like Cicchetti's approach 01 and AML [3] — automatically derive a transformation defini- 
tion from the difference between two metamodel versions. The existing approaches mostly use or extend 
existing model transformation languages and tools. 

To compare the different ways in which model migration can be defined, we propose a real-life case 
from the evolution of the Graphical Modeling Framework (GMF). The case is already well-researched, 
as it has been used in an empirical [5] and a comparative study ifTOll . It exhibits a number of differences 
to last year's migration case [ 12 ]: (1) Most of the metamodel remains the same which is more typical for 
model migration. (2) The migration is more complex and thus requires more expressive transformation 
languages. (3) GMF provides a reference migrator implemented in Java which defines the migration 
semantics. (4) GMF provides a number of test cases which can be used for validating the solutions. 



2 Graphical Modeling Framework 

The Graphical Modeling Framework (GMF^jis a widely used open source framework for the model- 
driven development of diagram editors based on the Eclipse Modeling Framework (EMF). GMF is a 
prime example for a Model-Driven Architecture (MDA) J6j , as it strictly separates platform-independent 
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(b) Implementation 
Figure 1 : Graphical Modeling Framework 



models (PIM), platform-specific models (PSM) and code. GMF is implemented on top of the Eclipse 
Modeling Framework (EMF^jand the Graphical Editing Framework (GEF^] Figure 1(a) shows the GMF 
dashboard which supports the process of creating the models of the diagram editor. 

The GMF models are based on a domain model expressed in Ecore from which an appropriate 
domain generator model can be derived. GMF provides wizards to derive the following models from 
the domain model: the graphical definition model defines the graphical elements like nodes and edges 
in the diagram, and the tooling definition model defines the tools available to author a diagram. The 
mapping model maps graphical elements from the graphical definition model and the tools from the 
tooling definition model to the constructs from the domain model. The mapping model is transformed 
into a diagram generator model from which a diagram editor can be generated. The diagram generator 
model can be altered to customize the code generation. 



Figure 1(b) shows the diagram editor generated from GMF models defined for a statemachine mod- 
eling language. The diagram editor shows the graphical elements in the diagram and the tools in the 
palette. GMF also provides more advanced features like e. g. annotating, zooming and layouting for the 
generated editor. The properties of a graphical element can be accessed through the properties view. 



3 Evolution of GMF Graph 

Here, we consider one of those metamodels — GMF Graph — to which graphical definition models have 
to conform. 

http : //www. eclipse . org/modeling/emf 
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(b) Model 



Figure 2: GMF version 1.0 



Figure 2(a) shows the part of the GMF Graph metamodel that has changed from GMF version 1 .0 to 
2. 1 as a class diagram. The GMF Graph metamodel describes the appearance of the generated diagram 
editor. The classes Canvas, Figure, Node, DiagramLabel, Connection, and Compartment are used to 



represent components of the diagram editor to be generated. Figure 2(b)| shows the model to define the 



graphical elements of the statemachine modeling language in a modified object diagram — objects that 
are contained in other objects by means of a composition are shown inside these objects. 

The evolution in the GMF Graph metamodel was driven by analyzing the usage of the Figure. refe- 
rencingElements reference, which relates Figures to the DiagramElements that use them. As described 
in the GMF Graph documentatiorj^J the referencingElements reference increased the effort required to 
reuse figures — a common activity for users of GMF. Furthermore, referencingElements was used only 
by the GMF code generator to determine whether an accessor should be generated for nested Figures. 

In GMF 2.1, the Graph metamodel was evolved to make reusing figures more straightforward by 



introducing a proxy for Figure, termed FigureDescriptor. Figure 3(a) highlights the changes that have 
been made to the GMF Graph metamodel. The original referencingElements reference was removed, and 
an extra class, ChildAccess, was added to make more explicit the original purpose of referencingElem- 



ents — accessing nested Figures. Figure 3(b) shows the migrated model of the graphical elements of the 
statemachine modeling language. Instances of FigureDescriptor and ChildAccess have been introduced 
as interfaces for the figures that can now be more easily reused using these interfaces. 

GMF provides a migrator that produces a model conforming to the evolved Graph metamodel from 
a model conforming to the original Graph metamodej^] In GMF, the migration is implemented in Java^] 
The version control system of GMF provides test models to validate the migrator which can be used to 
validate the submitted solution^] The GMF source code includes two example editors, for which the 
version control system contains versions conforming to GMF 1.0 and GMF 2.1. 



j http : //wiki . eclipse . o rg/GMFGraph_Hints 
5 http : //wiki . eclipse . org/GMF_Migration 
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root=Modeling_Pro j ect&view=log 
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Figure 3: GMF version 2.1 



4 Tasks and Criteria 



Core Task. The case consists of a core task and two extensions. The core task is to use a model trans- 
formation or migration tool to perform the migration explained in Section [3] Submissions are evaluated 
according to the following criteria: 

• Expressiveness: Is the language on which the transformation tool is based expressive enough to 
specify the migration? Or is it required to use a programming language to be able to completely 
specify the migration? 

• Correctness: Does the transformation correctly migrate the test cases included in the case re- 
sources? Does the transformation produce a model equivalent to the model migrated by the GMF 
migrator? 

• Conciseness: How much code is required to specify the transformation? Is the size of the code 
proportional to the number of differences between the metamodel versions or to the size of the 
metamodel versions? 

• Maintainability: How easy is it to read and understand the transformation? How easy is it to 
modify or extend the transformation? 

The case resources include the different GMF Graph metamodel versions as well as the test models. 

Multi-File Models. In GMF, models can be split over several files to be able to modularize them. 
When migrating a multi-file model, the modularization should be preserved by the transformation. In 
this extension, submissions should show that they are able to preserve the modularization into files. To 
facilitate this, the case resources include multi-file models for both metamodel versions. 

GMF Map metamodel. The GMF Map metamodel defines the structure to which mapping models 
need to conform. It has also been adapted from GMF 1.0 to GMF 2.1, but the migration is much more 
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simple than in case of GMF GraplfJ However, this migrating transformation poses a number of other 
challenges. (1) The GMF Map metamodel refers to other metamodels, and thus GMF Map models also 
refer to models of these metamodels. A transformation needs to be able to preserve these references. 
(2) The GMF Map metamodel has been released one more time than the GMF Graph metamodel. Thus, 
a transformation needs to detect the version of the model and appropriately migrate it to the newest 
version of the metamodel. To be able to do this, the transformation tool needs to be able to chain 
transformation definitions 0. In this extension, submissions should show that they are able to cope with 
these challenges. To facilitate this, the case resources include the different versions of the GMF Map 
metamodel as well as test models. 
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